ftp.cs.arizona.edu/ftp.cs.arizona.edu.tar/ftp.cs.arizona.edu/icon/newsgrp/group92c.txt/000049_icon-group-sender _Wed Oct 28 16:17:55 1992.msg

Internet Message Format | 1993-01-04 | 4KB

Received: by cheltenham.cs.arizona.edu; Fri, 30 Oct 1992 20:58:57 MST
Date: 28 Oct 92 16:17:55 GMT
From: uchinews!ellis![e-mail]  (Richard L. Goerwitz)
Organization: University of Chicago Computing Organizations
Subject: Re: confusing errors
Message-Id: <[e-mail]>
References: <[e-mail]>, <[e-mail]>, <[e-mail]>
Sender: [e-mail]
To: [e-mail]
Status: R
Errors-To: [e-mail]

[e-mail] writes:
>
>Now a language like Icon just doesn't commit to any easily explainable
>syntax - perhaps avoiding criticisms about its design, but only by the
>smokescreen method!

Actually, its syntax is very much like that of any Algol-like language.
If you get a chance some time, just take a look in the latest grammar
specs in _The Icon Programming Language_.  Some people (hackers mostly)
are turned off by its Pascal-ish look (because of course anything Pas-
calish looking must be evil :-)).

>|Maybe you are just baiting me, but the semicolon is not an operator with
>|abstract semantics. It has semantics only in the sense that it directs the
>|syntactic analyzer to map the concrete syntax to the abstract syntax in a
>|certain way.
>
>???? It's probably hopeless to direct you to the revised report on algol
>68 [this isn't a random insult, if you've seen the document you'll know
>exactly what I mean - it isn't exactly very readable], but if it doesn't
>have semantics somewthing is BADLY wrong with this language.

I'm making what I thought was a common distinction between concrete and
abstract syntax (see, e.g., Aho-Sethi-Ullman, section 2.5).  Some operators
only have relevance on the concrete level.  My point is that if such
operators can easily be dispensed with, we should do so.

>Tell me, can you characterise for me the circumstances under which a
>newline will NOT be interpreted as a go-on operator? When IS it safe to
>break an expression?

This is the key question.  It's really quite simple, and requires the ad-
dition of only about two hundred characters to the lexer.  Tokens can
either begin or end an expression (or both or neither).  This is intuitive.
For instance, if we get the operator := at the end of a line, then obviously
the expression isn't complete.  If, however, we get := and then an identi-
fier, then a newline, we have a complete expression and a SEMICOL (that's
what the Icon tokenizer calls it, I think) token can be emitted.  It's all
quite simple, and results in code that isn't cluttered with superfluous
directives.  You might think that this arrangement results in strange er-
rors, but in practice, one rarely makes an error that leads to unexpected
groupings.  In lvalue := rvalue, one might spell rvalue wrong.  One almost
never leaves rvalue out accidentally, though.  I can attest to this from
much experience.

Try working with a language for a few weeks that has automatic semicolon
insertion, and see whether you want to go back.  This argument can't be
settled in the abstract.

Here's an example of where a newline should be ignored.  Any Icon programmer
immediately recognizes the correct grouping, as I suspect even non Icon
programmers would.  The semicolon after the string is wholly useless, though
if you like it you can put it there:

procedure main()
    ident :=
    "this is an overlong line that just won't fit above, so I put it here"
    write(ident)
end

Here is an example of where semicolons are completely superfluous.  Can you
imagine a language that was so poorly designed that you had to insert a
useless operator all the time?

procedure main()
    ident := "hello";
    write(ident);
end

procedure main()
    ident := "hello"
    write(ident)
end

--

   -Richard L. Goerwitz              [e-mail]
   [e-mail]          rutgers!oddjob!ellis!goer